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Abstract 

The Secure Shell (SSH) protocol requires all im¬ 
plementations to support public key authentication 
method (“publickey”) for authentication purposes 
[2]. Hypertext Transfer Protocol (HTTP) appli¬ 
cations which provide a SSH client over the web 
browser need to support “publickey”. However, re¬ 
strictions in HTTP, such as Same Origin Policy, 
make it difficult to perform such authentications. 
In this document, a system to perform “publickey” 
authentication over HTTP is provided. It is en¬ 
sured that no compromise is made that would pose 
a security risk to SSH protocol. 

1 Introduction 

The Secure Shell (SSH) protocol is a protocol for 
secure remote login to servers. It computes a shared 
key through key exchange mechanisms, such as 
Difhe-Hellman key exchange [3], and establishes a 
secure channel for communication to servers. Users 
are authenticated through the secure channel using 
one of the accepted authentication methods. Com¬ 
monly used authentication methods include “pass¬ 
word” and “publickey”. As the name suggests, in 
case of “password” method, the user is simply re¬ 
quired to provide his/her password for authenti¬ 
cation. However, “publickey” method uses pub¬ 
lic/private key pairs for authentication. 

The Hypertext Transfer Protocol (HTTP) is an 
application-level protocol for data transfer across 
the internet. It is generic, stateless and can be used 
for purposes beyond hypertext. 

2 Authentication “publickey” 

In “publickey” authentication method. User creates 
a public/private key pair and adds the public key 
on the server. For successful authentication, the 
SSH protocol requires the message [2], shown be¬ 


low, to be signed by the private key of the user. 
And, the signed message should be verified by the 
server using the public key added by the user. On 
successful verification, authentication is successful 
and the user is permitted to login. 


string 

session identifier 

byte 

SSH_MSG_USERAUTH_REQUEST 

string 

user neime 

string 

service narnie 

string 

"publickey" 

boolean 

TRUE 

string 

public key algorithm name 

string 

public key blob 


The session identifier, shown above, is a seeret 
and is specific to that SSH session. 

It is common for private keys to be kept in an 
encrypted format for security reasons. However, 
this creates the hassle of decrypting the private key 
for authentication every single time. Authentica¬ 
tion agents, such as ssh-agent handle this by 
managing the decrypted private keys and signing 
messages for SSH clients on demand. 


3 Authentication agents 

ssh-agent implements OpenSSH agent protocol [1] 
to manage private keys and to sign messages. 
Clients connect to the agent, typically, over an 
UNIX domain socket to send requests and receive 
responses. UNIX domain socket is a special file in 
the file system. To restrict access, the special file 
has read/write permissions only for the user. 

If we could implement an authentication agent, 
similar to ssh-agent, that would manage private 
keys but accept signing requests over HTTP. That 
would be an agent which can enable SSH “pub¬ 
lickey” authentications through HTTP clients. 


1 


4 SSH Web Agent 

Here, we are defining a new authentication agent, 
ssh-webagent, which responds to authentication re¬ 
quests over HTTP. It accepts requests only from 
user and only on localhost And, due to same ori¬ 
gin policy, HTTP clients will not accept content 
from localhost unless Cross Origin Resource Shar¬ 
ing (CORS) |5] is enabled. It is also recommended 
that ssh-webagent accept HTTP requests over TLS 
[7] to avoid Mixed Content [5]. 

4.1 Trusted Servers 

On receiving an authentication request, it is impor¬ 
tant to identify the source of the request. A HTTP 
client could connect to ssh-webagent out of any web 
page, and without verification, a serious security 
risk exists. To verify the source, a combination of 
HTTP Referer header and public key of the server 
should be used. While the Referer header can be 
used to identify the public key of the server, the ac¬ 
tual verification is successful only if the signature 
provided by the server is valid. 

Server’s public key and HTTP Referer changes 
for each web application. It is therefore recom¬ 
mended that a trusted servers file is used to hold 
the public key of trusted servers along with the ex¬ 
pected values of HTTP Referer header. The trusted 
servers file should be kept safe to avoid unautho¬ 
rized modifications. A sample format for trusted 
servers file has been provided in Appendix [A| 

4.2 Identifiers 

HTTP is stateless and each request is independent 
of the other. Each HTTP request has a correspond¬ 
ing response but the order of HTTP requests and 
state, if any, shall be managed by the application. 

In case of authentication over a TCP connec¬ 
tion, a session is established and can be uniquely 
identified by However, HTTP provides 

no session and hence ssh-webagent has to establish 
a logical session to the trusted server and assign a 
unique identifier, ssh-webagent can interact with 
multiple trusted servers at the same time. And, 
ssh-webagent shall choose the unique identifier. 

The state of the authentication process shall be 
maintained in association with the identifier. How¬ 
ever, it should be noted that, a failure in the au¬ 
thentication process may not always be known to 
ssh-webagent. So, it is essential to maintain a rea¬ 
sonably short timeout for the authentication pro¬ 
cess, beyond which the identifier and its associated 
state is destroyed. 

^source IP address, source port, destination IP address, 
destination port, transport protocol 


4.3 Local User and Local Host 

Since ssh-webagent accepts authentication request 
on localhost, it shall be ensured that the request is 
from the same user who runs ssh-webagent. Support 
for this feature varies across operating systems and 
Appendix shows how the owner of a TCP con¬ 
nection can be identified on systems running Linux 
kernel. 

When ssh-webagent binds to a specific port on 
localhost, no other user will be able to use the same 
port. So, applications which intend to support mul¬ 
tiple local users, can choose multiple ports and send 
authentication request to all of them. A standard 
has been proposed to use a specific local IP address 
and port for ssh-webagent in Appendix [B| 

4.4 Session 

ssh-webagent shall establish a secure session with 
the trusted server before processing authentication 
requests. The session is initiated by a signed re¬ 
quest from the trusted server with Diffie-Hellman 
(DH)[^ parameters. On successful verification, ssh- 
webagent shall send a Diffie-Hellman response with 
an encrypted identifier. The secret established 
through Diffie-Hellman key exchange shall be used 
in the encryption of the identifier. And, once the 
trusted server successfully decrypts this identifier, 
the session is established. 

The authentication process following session cre¬ 
ation, will use the identifier in both clear and en¬ 
crypted data, ssh-webagent shall identify the ses¬ 
sion using the clear text identifier. However, it shall 
verify that the identifier in encrypted data matches 
the one in clear text. 

5 Proposed Protocol 

In this section, we define a protocol over HTTP 
that can be used for “publickey” authentication. It 
involves both session creation and authentication 
process. We start with the format of HTTP re¬ 
quests and responses before discussing each of them 
in detail. 

5.1 HTTP Request/Response 

The protocol uses base64 encoded messages 
in both HTTP request and response. HTTP 
request shall use method POST and content 
type application/x-www-form-urlencoded, 
while HTTP response shall use content type 
text/plain. HTTP request in this format will 
classify as simple cross-site request under CORS 
specification |^. 

^Diffie-Hellman Key Exchange algorithm[3] 
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P=[Message]&U=[User]&S=[Service] 

As a POST request, the key P shall be used to pass 
messages and, optionally, the keys U and S shall be 
used to pass user and service name^ respectively. 

[Message] 

The response body simply contains the message 
in response to the request and nothing more. 

5.2 Message 

Message is the basic unit of the protocol. A single 
message is received in the HTTP request and a sin¬ 
gle message is sent in the HTTP response. Message 
uses a binary format and data types used, in repre¬ 
sentation of the format, are as defined in RFC 4251 
|T], Section 5 “Data Type Representations Used in 
the SSH Protocols”. 


string 

“SSHWebAgent^ 

byte 

version 

byte 

type 

string 

data 


version shall indicate the version of the protocol 
and shall be used to check compatability of ssh- 
webagent and trusted server. 

VERSION_l_l 0x11 

type shall indicate the type of data the message 
holds. 

KEX_DH_REQUEST 0x02 

KEX_DH_RESPONSE 0x03 

PRIVATE 0x04 

data holds request parameters and response values 
in binary format. The format varies based on 
type and, hence, are described in their respec¬ 
tive sections. 

5.3 Session 

Session is initiated by a message from trusted server 
containing key exchange parameters and its sig¬ 
nature. The message will contain data of type 
KEX_DH_REQUEST in the format described be¬ 
low, 

mpint p 

mpint g 

mpint e 

string d 

string k 

string sign 

p, g are Difhe-Hellman key exchange parameters 
prime number and generator, respectively. 

®user and service names are part of SSH message, See 
Section 


e is the computed value of trusted server in key 
exchange 

d is session data, if any, added by trusted server. 
It shall be used by ssh-webagent without any 
interpretation. 

k, sign are the public key and signature, of the 
trusted server, represented in their respective 
formats as defined in RFC 4253 [3], Section 6.6 
“Public Key Algorithms”. 

5.3.1 Verification 

On receiving the message, ssh-webagent uses the 
trusted servers file and checks if the public key and 
the HTTP Referer are trusted. On a successful 
match, the message shall be checked for authen¬ 
ticity through signature verification. The following 
values are used in the specified order for signing 
and verification, 

mpint p 

mpint g 

mpint e 

string method 

string referer 

string k 

string d 

method shall be the method used in HTTP re¬ 
quest. As mentioned in Section [5T| this shall 

be POST. 

referer shall be the value of Referer field in HTTP 
request header. 

5.3.2 Response 

On successful verification of signature, ssh-webagent 
shall send a message containing data of type 
KEX_DH_RESPONSE in the format described 
below, 

mpint f 

string E 

f is the computed value of ssh-webagent in key ex¬ 
change. 

E is the encrypted message body of type NEW 
viewable only by trusted server, message body 
is described, in detail, in Section |5.4[ 

5.3.3 Secret 

The secret S is computed by ssh-webagent through 
Difhe-Hellman key exchange and it is used to com¬ 
pute a shared secret, a secret key and an initializa¬ 
tion vector. 
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1 . 


2 . 


5.4.2 ciphertext and plaintext 


Shared Secret 

shared secret is the computed hash of the fol¬ 
lowing values using 256-bit Secure Hash Algo¬ 
rithm (SHA-256) [HI- 


string 

method 

string 

referer 

mpint 

e 

mpint 

f 

mpint 

S 

Secret Key 

secret key shall be used 

as the key for symmet- 

ric encryption. A SHA-256 hash of the follow¬ 

ing values is the secret key. 

mpint 

S 

string 

shared secret 

byte 

’A’ 

string 

referer 


The encrypted contents of ciphertext, namely the 
plaintext, shall be in the format specified below, 

byte [4] random 

byte type 

string identifier 

payload 

byte[n] padding 

random shall be a 32-bit (4 bytes) cryptographi¬ 
cally secure random number. 

type indicates the message body type and it shall 
be used to interpret the payload. The sup¬ 
ported types are listed below, 


NEW 


0x02 

AUTH 

REQUEST 

0x03 

auth" 

RESPONSE 

0x04 


3. Initialization Vector 

Depending on the encryption algorithm, if 
needed, the initialization vector can be ob¬ 
tained by computing a SHA-256 hash of the 
following values. 


mpint 

S 

string 

shared secret 

byte 

’B’ 

string 

referer 


Once the trusted server receives the response mes¬ 
sage. It computes its own values for the above and 
decrypts the message body. 

5.4 Message Body 

The message body holds the cipher text for commu¬ 
nication between ssh-webagent and trusted server. 
It also includes the session identifier and the en¬ 
cryption algorithm for decryption purposes. The 
type of message body and its related contents are 
encrypted and stored in cipher text. 

5.4.1 format 


identifier is the session identifier and it shall be 
the same as identifier defined in Section [5.4. 1| 

payload shall be zero or more bytes of message 
content. The format of payload depends on 
message body type and they are described in 
detail in their respective sections. 

padding shall be zero or more bytes of random 
padding to meet the block size requirements of 
encryption algorithms. 

5.4.3 NEW 

First message with a message body, in a session, is 
always of type NEW. This message is sent by ssh- 
webagent to trusted server. The format of plaintext 
in message body of type NEW is shown below. 


byte [4] 

random 

byte 

type 

string 

identifier 

byte[n] 

padding 


It should be noted that payload is empty and, 
hence, is not shown in plaintext. 


The binary format of message body is shown below, 

byte algorithm 

string identifier 

string ciphertext 

algorithm used for encryption can be identified 
using this field. Currently supported encryp¬ 
tion algorithms and their respective values are 
listed below, 

AES 256 CBC 0x02 


5.5 Authentication 


The authentication process shall be initiated by 
trusted server after establishing a session. The 
messages used in the process are as defined in Sec¬ 
tion 5.2 and shall contain message body as data and 
shall use type PRIVATE. 


5.5.1 Request 

A request for “publickey” authentication is sent by 
the trusted server in the form of a message con¬ 
taining data of type PRIVATE and message body 
of type AUTH_REQUEST. 


identifier is the session identifier. 

ciphertext is the encrypted part of message body. 
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This request provides the secret SSH session 
identif iei|^required to generate SSH message for 
signing and authentication. The format of the re¬ 
quest message is shown below, 

string “SSHWebAgent” 

byte VERSION_l_l 

byte PRIVATE 

string message body 

The format of message body is as follows, 

byte algorithm 

string identifier 

string ciphertext 

And, the format of plaintext that is encrypted to 
form the ciphertext is, 

byte [4] random 

byte AUTH_REQUEST 

string identifier 

string SSH session identifier 

byte[n] padding 

SSH session identifier is as defined in RFC 
4253 [3], Section 7.2, “Output from Key Exchange” 

5.5.2 Response 

In response to the request, ssh-webagent shall use 
SSH session identifier, construct the SSH mes¬ 
sage and sign it with one or more private keys of 
the user. The resulting signatures are sent securely 
in a response message to the trusted server for suc¬ 
cessful authentication. The format of plaintext in 
response message is as follows, 


byte [4] 

random 

byte 

AUTH_RESPONSE 

string 

identifier 

boolean 

status 

string 

signatures 

string 

options 

byte[n] 

padding 


status shall indicate whether the signing process 
was successful or not. It shall be used to com¬ 
municate failures to trusted server. 

signatures contain one or more signatures of the 
SSH message, along with the corresponding 
public key and comments, if any. They are 
formatted as follows, 

uint32 n 

string[n] item 

And, each item shall use the format shown be¬ 
low, 

^session identifier as shown in SSH message, Section IH 


string publickey 

string signature 

string comment 

string[n] shall represent multiple strings, with 
the number of strings indicated by n. When 
n is zero, string[n] shall be empty and, hence, 
shall not be present. 

options shall be used to pass information to the 
trusted server in the form of key-value pairs. 
It shall use the format as specified below, 

uint32 n 

byte es 

string[n] option 

And, each option shall hold a key and a value 
as shown below, 

string key 

string value 

The value shall be encrypted using an en¬ 
cryption scheme es. The following encryption 
schemes shall be supported, 

PKCSl_RSAES_OAEP 0x02 

PKCSl_RSAES_OAEP encryption scheme 
shall use the public key of trusted server to 
encrypt the value. 

On receiving the response message, the trusted 
server shall have all that it needs to perform “pub¬ 
lickey” authentication in Secure Shell (SSH) proto¬ 
col. 

6 Performance 

The authentication method ensures that the remote 
login to server is secure. But, for the task at hand, 
it is most likely a hindrence and sooner it is done, 
the better. The primary contributing factors to 
longer authentication time would be network la¬ 
tency to trusted server. Data encryption, signing 
and verification are reasonably quick on modern 
processors and are negligible in comparison. The 
latency to web agent will also be negligible since it 
resides on localhost. 

The protocol uses HTTP requests to receive 
and send messages. Hence, session establishment 
and authentication process will each require three 
HTTP requests, when done synchronously. First 
request shall be used to get the message (request) 
from trusted server, second request shall be used to 
pass the message (request) to web agent and receive 
a message (response) and the final request shall 
be used to pass the message (response) to trusted 
server. With two requests to trusted server per ses¬ 
sion establishment and authentication process. A 
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total of four requests to trusted server remain the 
primary contributing factors to performance. 

HTTP request to trusted server will be over TLS. 
Hence, apart from the usual TCP connection ne¬ 
gotiation, a TLS session negotiation will also hap¬ 
pen when a new connection is established. So, the 
first request will take a significantly longer time, 
in comparison to subsequent requests to trusted 
server. The total time taken to complete four re¬ 
quests can be significant and can be a hinderance. 
To achieve better performance, it is recommended 
that the network latency to trusted server remains 
below 80ms. 

7 Conclusion 

Secure Shell protocol has been commonly used for 
remote login to servers. It is the first step to man¬ 
aging servers remotely. As the number of servers in¬ 
crease, the problem of logging to multiple servers, 
a time consuming task, become apparent. These 
problems can be solved to an extent through appli¬ 
cations which abstract out and automatically login 
to servers. However, these applications may require 
the private key of user for automatic login. 

In a world with increasing use of virtualization, 
more and more servers (or virtual servers) are pur¬ 
chased from providers and managed remotely over 
public internet using a web browser. In the ab- 
sense of a method for secure remote login to these 
servers, users are left to use traditional tools for lo¬ 
gin or at worst, take a security risk and, give away 
the private key to third-party applications. 

Hence, solving the problem of secure remote lo¬ 
gin (“publickey”) over the web, ie., HTTP, will open 
doors for easier access to servers. And, bring back 
private keys to the hands of the user. When com¬ 
bined with a powerful server management applica¬ 
tion, this can bring servers to general public, who, 
without any technical knowledge, can avail inter¬ 
net services through their servers in a decentralized 
manner. 
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A Trusted Servers File 


The public kej0 of trusted server and its accept¬ 
able HTTP Referer prefixes are the contents of this 
file. Each trusted server has an entry starting with 
its public key on the first line, followed by one or 
more acceptable prefixes of HTTP Referer values 
per line. The entry for trusted server ends with a 
line containing a single dot (.), followed by an entry 
for next trusted server. 


A sample trusted servers file in this format has 


been shown below, 

1 AAAAB3NzaClyc2EAAAADAqABAAABA 
QCrLJj gFEA7tLyydh5eS2DCglbS5/ 
767i5MaCoXoxZAphI/JqTD62nYJ6P 
G0hYu8spE2kcTtNH10mcsygFEaa8v 
lFjxYL7dW/HuQfayQ+eHZq/xPtTlu 
oSQW6yI9qKjIfnaxF9IHtdZV0kcSw 
uEmlJfKj ogf6Nbyn8M+biMK6Py5K4 
sll0sN48WGYEz9Xe8CcZJdhCyw97f 
hPELlXwCqvQj GqXpekSWTe41piqKv 
1Zn6T7/E5VW0mvu419WkLlAU7qZlx 


2 

3 

4 

5 

6 


fW5bf qggXnGnmOSawRGWzFaOEt sHJ 
Wn41c//0HiWYj 0MRkLd7+VVsBEF+0 
C2IAzJ4QyQtlecLkmu5Yfq/Z 
https;//webssh.exaunple.com/ssh/ 
https;//webssh.excunple.com;444/ssh/ 
https;//webssh.excunple.com;445/ssh/ 

AAAAB3NzaClyc2EAAAADAqABAAABA 
qOPyj19euMq4Crj/0VyP69+ltELAM 
4Wt0GyG8y3ENEtpa/qvOXc J11Z813 
lRRWt5+cune2LKqjwInKlxo3UqL+Jd 
CA10X9hlap8w0WEm6ZHiehB0JNe7B 
gIwPY169qLpv48Xywtz28BahxZPSD 
d7k5NxiH4HIUbau3tHlvs02L0qj 9p 
qOPEDh+GdmMcgEvOZqMY9B6uKJqI+ 


RdiDgWHNDUW+pFwRi2xzMFqqPCqC0 

7ykKMI8G/N13q7RquDiRw9AhO/Brd 

FlNEa3I4fyg09nPkBP351kBrL117V 

PgoVP24VZJkZSojEKnp4KkIhGLTfg 

+5TqI6kx36blHZpx3g8txAqt 

7 https;//sshclient.example.com/ 
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B Local IP, Port and Domain 

SSH Web Agent binds to local loopback address 
and accepts request on localhost. The IPv4 address 
range assigned for local loopback is 127.0.0.0/8]^ 
Any address in this range can be used by web 
agent for accepting requests. However, for easier 
inter-operability, the IPv4 address, in this range, 
127.82.11.29 and port number 8211 is suggested 
for use. 

® Public key should be in a format as defined in RFC 4253 
l3l . Section 6.6 “Public Key Algorithms” 

®RFC 6890, “Special-Purpose IP Address Registries” 


HTTP/TLS protocol requires web agent to use a 
TLS certificate signed by a trusted certificate au¬ 
thority. TLS certificates are, typically, issued for a 
domain instead of an IP address. 

TLS certificate and its private key will need to 
be distributed along with web agent. Hence, they 
should be considered public. And, on the same 
note, for security reasons, it is recommended that 
the entire domain is considered public and subdo¬ 
mains are not used for any other purpose. 

The domain localhost-ssh-webagent.in has 
been assigned for this purpose and it resolves to the 
suggested IPv4 address, 127.82.11.29. The whois 
information for localhost-ssh-webagent.in provides 
the current contact to obtain TLS certificates. 


C Connection Owner 


A web agent listening on loopback interface can be 
connected to by any user. This results in a privilege 
escalation and unauthorized access to private key. 
This security issue can be mitigated by ensuring 
that the remote end of the local connection belongs 
to the owner of the web agent process itself. The 
premise here is that the owner of the web agent 
process is given access to the private key and hence 
can allow access to the same user. 

On linux kernels, /proc/net/tcp provides a for¬ 
matted output of active connections. In this out¬ 
put, the columns local_ address, rem_ address and 
uid are of relevance to us. The IPv4 address and 
port in the output are shown in hexadecimal. 

The sample output below shows the web agent 
listening on 127.82.11.29;8211 (1), a SSH server lis¬ 
tening on 0.0.0.0;22 (2) and a SMTP server listen¬ 
ing on 127.0.0.1;25 (3). It should be noted that the 
uid for web agent is 1000, indicating a user, while 
the uid for others is, 0 indicating the superuser. 

I local_address rem_address uid 

1 1D0B527F;2013 00000000;0000 1000 

2 00000000;0016 00000000;0000 0 

3 I 0100007F;0019 00000000;0000 0 

The sample output below shows active local 
connections. 


local_address 

1D0B527F;2013 

1D0B527F;2013 

1D0B527F;2013 

0100007F;CE93 

0100007F;CE94 


rem_address 
00000000;0000 
0100007F;CE93 
0100007F;CE94 
1D0B527F;2013 
1D0B527F;2013 


uid 


1000 

listener 

1000 

accept 

0 

reject 

1000 

- 

0 

- 


Using the output above, web agent can easily 
compare the uid of connection with the process uid. 
In case of a mismatch, the connection has origi¬ 
nated from a different user and should be rejected. 
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